home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-20 / tcp90135.zip / TCP90135.TXT < prev   
Text File  |  1990-09-14  |  15KB  |  390 lines
  1. Path: tosspot!indep1!pete
  2. From: pete@indep1.UUCP (Peter Franks)
  3. Newsgroups: to.tosspot
  4. Subject: TCP Digest #135
  5. Message-ID: <1336@indep1.UUCP>
  6. Date: 14 Sep 90 01:25:59 GMT
  7. Reply-To: pete@indep1.MCS.COM (Peter Franks)
  8. Followup-To: to.tosspot
  9. Distribution: to
  10. Organization: as little as possible
  11. Lines: 377
  12.  
  13. TCP-Group Digest            Tue, 11 Sep 90       Volume 90 : Issue 135
  14.  
  15. Today's Topics:
  16.                             Administrivia
  17.                            Choosing an SSID
  18.                               Mailbox ID
  19.                         RSPF problems (3 msgs)
  20.                            SSID's (2 msgs)
  21.                     SSIDs and NETROM IDs  (5 msgs)
  22.                             SSIDs in Italy
  23.                         TAPR 1.1.7 KISS broken
  24.  
  25. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>
  26. Send requests of an administrative nature (addition to, deletion from the
  27. distribution list, et al) to: <ListServ@UCSD.Edu>
  28.  
  29. Archives of past issues of the TCP-Group Digest are available
  30. (by FTP only) from UCSD.Edu in directory "mailarchives".
  31. ----------------------------------------------------------------------
  32.  
  33. Date: Mon, 10 Sep 90 08:44:38 -0700
  34. From: brian (Brian Kantor)
  35. Subject: Administrivia
  36. To: tcp-group
  37.  
  38. Will whoever is redistributing or forwarding this mailing list to a uucp
  39. site 'nipper' please stop.  The mail is bouncing.
  40.  
  41. Note that if you are forwarding or redistributing this mailing list, you
  42. MUST arrange that errors caused by your actions go to YOU and not to me.
  43. If you don't know how to do that, you've got no business redistributing
  44. the damn list!
  45.     - Brian
  46.  
  47. ------------------------------
  48.  
  49. Date: Mon, 10 Sep 90 10:28:47 EDT
  50. From: mjj@stda.jhuapl.edu (Marshall Jose)
  51. Subject: Choosing an SSID
  52. To: tcp-group@ucsd.edu
  53.  
  54. Jeff writes:
  55.  
  56. > ....
  57. > -15 The first hop from a netrom.
  58. > 
  59. > The -9 for TCP/IP and Netrom is because initially most connects
  60. > to the TCP/IP stations were via Netrom connections.
  61. > 
  62. > It seems that -7 is the international designation for KA-Nodes.
  63.  
  64. As I understand Net/Rom transport, an AX.25 station's SSID will be
  65. complemented and used as the call for transport on the first hop.
  66. I noticed this when I connected to a Net/Rom node as WA3VPZ-1, and
  67. saw my call "repeated" as WA3VPZ-14.  Presumably no further complements
  68. occur as additional hops are initiated.
  69.  
  70. So:  Using -8 as the TCP/IP designator gives a complement of -7,
  71. possibly conflicting with KA-Nodes.  And so on.
  72.  
  73.  
  74.  
  75. Marshall Jose  WA3VPZ
  76. mjj%stda@aplcen.apl.jhu.edu  ||  ...mimsy!aplcen!aplvax!mjj
  77.  
  78. ------------------------------
  79.  
  80. Date: Mon, 10 Sep 90 15:10:57 EDT
  81. From: rutgers!wb3ffv.ampr.org!howardl (Howard Leadmon - WB3FFV)
  82. Subject: Mailbox ID
  83. To: crompton@nadc.nadc.navy.mil (D. Crompton)
  84.  
  85.    Hello Doug,
  86.  
  87. > A local BBS operator has requested that the NOS BBS ID be changed
  88. > from [NET-$] to [NET-H$] - this was done in net towards the end but
  89. > somehow got lost in NOS.
  90.  
  91. So tell us, what is the difference between [NET-$] and [NET-H$] ??
  92. I have seen the first, but the inclusion of the H is new to me...
  93.  
  94. -------------------------------------------------------------------------------
  95. Internet  : howardl@wb3ffv.ampr.org    |    Howard D. Leadmon
  96. UUCP      : wb3ffv!howardl        |    Advanced Business Solutions
  97. TELEX     : 152252474             |    210 E. Lombard St - Suite 410
  98. Telephone : (301)-576-8635        |    Baltimore, MD  21202 
  99.  
  100. ------------------------------
  101.  
  102. Date: Mon, 10 Sep 90 07:37:12 PDT
  103. From: "k1io@FN42jk  10-Sep-1990 1027" <goldstein@carafe.enet.dec.com>
  104. Subject: RSPF problems
  105. To: tcp-group@ucsd.edu
  106.  
  107. Look at the bright side:  You're making history just trying it. 
  108. Unlike TCP and IP, RSPF was designed for packet radio use, and nobody
  109. has ever coded it before Anders, nor tried it before recently. So
  110. we're really looking at the first lab testbed, and should expect
  111. results accordingly..
  112.  
  113. That means we're simultaneously debugging the protocol and the
  114. implementations.  I can only comment on protocol issues.  One 
  115. question that I think came up last year was about hard-coded routes.
  116. When designing the auto-routing protocol, I wasn't thinking about
  117. manual routing, but it obviously exists and will remain there, at
  118. least until (and probably after) auto routing is dominant.
  119.  
  120. Should manual entries override or be overriden by RSPF?  I don't
  121. think there's a good answer.  Today, with RSPF still "experimental",
  122. it's probably prudent for the manually-set tables to override whatever
  123. RSPF does.  That means you'll have an RSPF-generated route table
  124. and a manual one, and the manual one wins if it's set. That allows
  125. RSPF to run in "play" mode, without really changing traffic, for
  126. existing routes.  Once RSPF stabilizes, though, you'd probably want
  127. to switch RSPF to become dominant over manual routes; the manual
  128. routes become sort of an initialization value that NOS uses before
  129. RSPF has found better paths.
  130.  
  131. That probably calls for a parameter so you can choose whether manual
  132. or RSPF dominates.  In any case, the manual table should not be
  133. munged by RSPF.  That's probably bad network theory and it may want
  134. to be changed in the future, but we still have to figure out whether any
  135. given anomaly is code or protocol, so for the moment...
  136.     fred k1io
  137.  
  138. ------------------------------
  139.  
  140. Date: Mon, 10 Sep 90 18:09:33 +0200
  141. From: klemets@sics.se
  142. Subject: RSPF problems 
  143. To: crompton@nadc.nadc.navy.mil (D. Crompton)
  144.  
  145. > Maybe someone could explain what we should see? Should we see routes
  146. > added in the route list? Can hard coded routes still exist and not
  147. > be bothered?
  148.  
  149. Yes you should see new routes appear in the routing table. If you have
  150. any manually entered routes that refer to the same station as the
  151. route generated by RSPF, they will be replaced with the RSPF generated
  152. route. This is a difference between the 2.0 and 2.1 implementations.
  153. Ok, so I introduced a bug here. It turns out that all permanent routes
  154. are being deleted. I have sent Kelvin a patch that fixes this problem.
  155. I have also updated my archive at sics.se.
  156.  
  157. When it comes to the problem with ARP, that really beats me. I have
  158. just added one single line to arp.c, that is all.
  159.  
  160. There are some hacks done in the RSPF code to allow broadcasting on
  161. several different interfaces. I hope to clean this upp by adding
  162. multicast support to the IP layer, as specified in RFC-1112. This
  163. would include IGMP (Internet Group Management Protocol.)
  164.  
  165. Anders
  166.  
  167. ------------------------------
  168.  
  169. Date: Mon, 10 Sep 90 15:43:19 CDT
  170. From: Jay Maynard <jmaynard@thesis1.hsch.utexas.edu>
  171. Subject: RSPF problems 
  172. To: klemets@sics.se, tcp-group@ucsd.edu
  173.  
  174. I saw the one-line difference in arp.c, too...Which version of NOS did you
  175. start with when making changes? Perhaps there's a subtle incompatibility there.
  176. I did find two typos in rspf.c - mbuf was spelled mubf in one place, and
  177. router was spelled rotuer. Perhaps I need to snarf the current version of
  178. your archive. One other note: I put the FORTH interpreter in at the same time,
  179. and merged the config.c changes from the RSPF code into that one, since it
  180. matched the original config.c more closely. Why the maxstk value of 200 for
  181. the killer? I put it back to 512. That's all I did to the code... :-)
  182.  
  183. ------------------------------
  184.  
  185. Date: Mon, 10 Sep 90 9:52:21 PDT
  186. From: Brian Lloyd <brian@robin.telebit.COM>
  187. Subject: SSID's
  188. To: tcp-group@ucsd.edu
  189.  
  190. Everyone has a different "standard", "official" SSID's are not part of
  191. the protocol, and it seems unlikely that this group will ever bring
  192. the rest of the world "in line", and . . .
  193.  
  194.                         does it really matter?
  195.  
  196. 73 de Brian, WB6RQN
  197.  
  198. ------------------------------
  199.  
  200. Date: Mon, 10 Sep 90 15:32:36 EST
  201. From: bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
  202. Subject: SSID's
  203. To: tcp-group@ucsd.edu
  204.  
  205. >Everyone has a different "standard", "official" SSID's are not part of
  206. >the protocol, and it seems unlikely that this group will ever bring
  207. >the rest of the world "in line", and . . .
  208. >
  209. >                        does it really matter?
  210. >
  211. >73 de Brian, WB6RQN
  212.  
  213.  
  214. I thought it was decided a couple years ago (after much heated debate)
  215. that SSID's have no real meaning and attempting to apply meaning to them
  216. was a bad idea.
  217. Or is my memory really that bad??  :-)
  218.  
  219. bill    KB3YV
  220.  
  221.                                           bill gunshannon
  222.                                        702WFG@SCRVMSYS.BITNET
  223.  
  224. ------------------------------
  225.  
  226. Date: Mon, 10 Sep 90 7:31:18 CDT
  227. From: Jay Maynard <jmaynard@thesis1.hsch.utexas.edu>
  228. Subject: SSIDs and NETROM IDs
  229. To: tcp-group@ucsd.edu
  230.  
  231. There's not much standard around here, except for TCP/IP users using -8 (and
  232. up for multiple stations). We have no standard for NETROM IDs yet, but I've
  233. proposed one which may gain some acceptance:
  234. Take the low order 24 bits of the IP address. Use the top 4 bits to form one
  235. hex digit, and then take the remaining 20 bits in groups of 5 to make 4
  236. base-32 digits in the range 0-9a-v. Put a leading # to make the name private.
  237. Example: My IP address is 44.76.0.92. This makes:
  238.         44              76              0               92
  239. 0 0 0 1 1 1 0 0|0 1 0 0 1 1 0 0|0 0 0 0 0 0 0 0|0 1 0 1 1 1 0 0
  240. (ignore this)  |   4   |    O    |    0    |    2    |    S
  241.  
  242. This is guaranteed to be unique for all AMPRNET hosts. The bit-twiddling
  243. can be done by a simple C routine, and might even be built into the netrom
  244. commands in NOS. I know there's been a similar scheme mentioned on
  245. Compu$erve, but that one (using the hex representation of the low 16 bits)
  246. would break down at the edges of the assignment areas.
  247.  
  248. Comments, anyone?
  249.  
  250.  
  251. ------------------------------
  252.  
  253. Date: Mon, 10 Sep 90 09:51:34 MDT
  254. From: Bdale Garbee <bdale@col.hp.com>
  255. Subject: SSIDs and NETROM IDs 
  256. To: tcp-group@ucsd.edu
  257.  
  258. > This is guaranteed to be unique for all AMPRNET hosts. The bit-twiddling
  259. > can be done by a simple C routine, and might even be built into the netrom
  260. > commands in NOS. I know there's been a similar scheme mentioned on
  261. > Compu$erve, but that one (using the hex representation of the low 16 bits)
  262. > would break down at the edges of the assignment areas.
  263.  
  264. > Comments, anyone?
  265. >  
  266.  
  267. We use the hex representation of the low-order 24 bits, and don't use the
  268. leading pound... no value is seen by making IP nodes "private" in the NET/ROM
  269. sense around here.  With six allowable digits of callsign, and the relative
  270. ease of dealing with pure hex, we think this is a win.
  271.  
  272. So, I'm 200001:N3EUA, aka [44.32.0.1] for the machine on the air.
  273.  
  274. Bdale
  275.  
  276. ------------------------------
  277.  
  278. Date: Mon, 10 Sep 90 14:18:10 edt
  279. From: Kurt_Freiberger@dgc.ceo.dg.com
  280. Subject: SSIDs and NETROM IDs
  281. To: tcp-group@UCSD.EDU
  282.  
  283. CEO summary:
  284.   There IS a value to having the Net/Scam IDs "hidden".  The 
  285. mainstream NET/Scam'ers have a tendency to try to connect to every 
  286. node they can find.  If one doesn't want this to happen, one hides it 
  287. with the #.  Also, the mainstreamers complain about the size of the 
  288. nodes lists.
  289.  
  290. Cheers.
  291. ---
  292. Kurt Freiberger, WB5BBW / voice 713.877.8222 / FAX 713.622.3649   
  293. amprnet 44.76.0.1 / PBBS: WB5BBW @ WB5BBW.#HOU.TX.USA.NA          
  294. Data General Corp.  Houston, TX / "Anyone for Iraq of Lamb"??     
  295. Get someone else's opinion.  I'm keeping mine.
  296.  
  297. ------------------------------
  298.  
  299. Date: Mon, 10 Sep 90 15:35:16 CDT
  300. From: Jay Maynard <jmaynard@thesis1.hsch.utexas.edu>
  301. Subject: SSIDs and NETROM IDs 
  302. To: bdale@col.hp.com (Bdale Garbee)
  303.  
  304. > We use the hex representation of the low-order 24 bits, and don't use the
  305. > leading pound... no value is seen by making IP nodes "private" in the NET/ROM
  306. > sense around here.  With six allowable digits of callsign, and the relative
  307. > ease of dealing with pure hex, we think this is a win.
  308.  
  309. Hm. We use private names to encourage people to use the real TheNet nodes
  310. (we've completely gotten rid of NetScam in the Houston area) instead of going
  311. through the KA9Q leaf nodes. Is this realistic?
  312.  
  313. ------------------------------
  314.  
  315. Date: Mon, 10 Sep 90 14:32:09 MDT
  316. From: Bdale Garbee <bdale@col.hp.com>
  317. Subject: SSIDs and NETROM IDs 
  318. To: tcp-group@ucsd.edu
  319.  
  320. > CEO summary:
  321. >   There IS a value to having the Net/Scam IDs "hidden".  The 
  322. > mainstream NET/Scam'ers have a tendency to try to connect to every 
  323. > node they can find.  If one doesn't want this to happen, one hides it 
  324. > with the #.  Also, the mainstreamers complain about the size of the 
  325. > nodes lists.
  326.  
  327. Ok, what you're really saying is that you've responded to pressure from the
  328. "locals".  That's fair.  Here, the majority of use of the NET/ROM "network" 
  329. (note carefully placed quotation marks!) is for TCP/IP and PBBS forwarding... 
  330. and our node population and configuration is such that it's a pain to get 
  331. anything useful in the nodetable... size has never been an issue.
  332.  
  333. I hate running IP over NET/Wrong, but we've got a lot of work left to do before
  334. I can kiss it off forever...
  335.  
  336. Bdale
  337.  
  338. ------------------------------
  339.  
  340. Date: Mon, 10 Sep 1990 17:30:37 EDT
  341. From: ZAGNI@CDDIS.GSFC.NASA.GOV   (Luca Bertagnolio, IK2OVV)
  342. Subject: SSIDs in Italy
  343. To: tcp-group@ucsd.edu
  344.  
  345. Folks,
  346. here is the "standard" for SSIDs in Italy (in quotes because this is most
  347. used, but there are also others in use):
  348. -0 standard terminal AX.25 (eg. cmd:)
  349. -1 PBBS (eg. PacCom PMS, Kantronics) built-in on the TNCs
  350. -2 dumb AX.25 gateways (UHF-VHF)
  351. -3 KAnodes
  352. -8 PBBS (RLI, MBL, etc.)
  353. Also, Net/ROM and TheNet use -2 for the 2-meter band, -7 for 70 cm and
  354. -12 for 1.2 GHz.
  355. As you can see the SSID for TCP/IP is not fixed, partly because of the
  356. lack of someone coordinating the effort; IMHO, 1200 bps is too slow a speed
  357. for TCP/IP, you will always have a stupid guys setting the parameters in
  358. his fashion, and collapsing the net.
  359. Anyway, Brian, you are right! ;-)
  360. 73, Luca
  361. Milan, Italy
  362.  
  363. ------------------------------
  364.  
  365. Date: Mon, 10 Sep 1990 17:24:04 EDT
  366. From: ZAGNI@CDDIS.GSFC.NASA.GOV   (Luca Bertagnolio, IK2OVV)
  367. Subject: TAPR 1.1.7 KISS broken
  368. To: k3mc@apple.com, tcp-group@ucsd.edu
  369.  
  370. Mike et al,
  371. Stefano IK2OYD here in Milan has just finished to make some tests on
  372. the code; it *definitely* is broken, because when you run half-duplex
  373. the delay introduced by the persist is waited, the the TNC goes in TX.
  374. With full-duplex on you always get an instant TX, no matter of the persist
  375. (and that's OK).
  376. So, who's the guy willing to fix this? Also, is the source for this code
  377. available somewhere?
  378. 73, Luca
  379.  
  380. ------------------------------
  381.  
  382. End of TCP-Group Digest
  383. ******************************
  384.  
  385. -- 
  386. +------------------------------------------------------------------------------+
  387. |  Peter Franks  |          pete@indep1.mcs.com  OR  pete@indep1.uucp          |
  388. |      NI9D      |                   Use whichever one works                   |
  389. +------------------------------------------------------------------------------+
  390.